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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



rd , 



The present document is part of a TS-family covering the 3 Generation Partnership Project Technical Specification 
Group Services and System Aspects, Telecommunication management; as identified below: 

32.521: Self-Organizing Networks (SON) Policy Network Resource Model (NRM) Integration Reference 

Point (IRP): Requirements 

32.522: Self-Organizing Networks (SON) Policy Network Resource Model (NRM) Integration 

Reference Point (IRP): Information Service (IS) 

32.526: Self-Organizing Networks (SON) Policy Network Resource Model (NRM) Integration Reference 

Point (IRP): Solution Set (SS) definitions 
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Scope 



The present document is part of an Integration Reference Point (IRP) named Self Organizing Networks (SON) Policy 
Network Resource Model (NRM) IRP, through which an IRP Agent can communicate management information to one 
or several IRPManagers concerning SON policies. The SON policy NRM IRP comprises a set of specifications defining 
Requirements, a protocol neutral Information Service and one or more Solution Set(s). 

The present document specifies the protocol neutral SON policy NRM IRP: Information Service (IS). 

In order to access the information defined by this NRM, an Interface IRP such as the "Basic CM IRP" is needed (3GPP 
TS 32.602 [11]). However, which Interface IRP is applicable is outside the scope of the present document. 

The present document also contains stage 2 descriptions for those functionalities for the Self-Optimization OAM, SON 
coordination and Energy Saving Management. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32.150: "Telecommunication management; Integration Reference Point (IRP) Concept 

and definitions". 

[4] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[5] 3GPP TS 32.521: "Telecommunication management; Self-Organizing Networks (SON) Policy 

Network Resource Model (NRM) Integration Reference Point (IRP): Requirements". 

[6] 3GPP TS 36.331: "Technical Specification Group Radio Access Network; Evolved Universal 

Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification". 

[7] 3GPP TS 36.423: "Technical Specification Group Radio Access Network; Evolved Universal 

Terrestrial Radio Access Network (E-UTRAN); X2 Application Protocol (X2AP)". 

[8] 3GPP TS 32.425: "Technical Specification Group Services and System Aspects; 

Telecommunication management; Performance Management (PM); Performance measurements; 
Evolved Universal Terrestrial Radio Access Network (E-UTRAN)" 

[9] 3GPP TS 32.622: "Telecommunication management; Configuration Management (CM); Generic 

network resources Integration Reference Point (IRP): Network Resource Model (NRM)" 

[10] 3GPP TS 32.762: "Telecommunication management; Configuration Management (CM); Evolved 

Universal Terrestrial Radio Access Network (E-UTRAN) network resources Integration Reference 
Point (IRP): Network Resource Model (NRM)" 

[II] 3GPP TS 32.602: "Telecommunication management; Configuration Management (CM); Basic CM 
Integration Reference Point (IRP) Information Service (IS)". 
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[12] 3GPP TS 36.413: "Technical Specification Group Radio Access Network; Evolved Universal 

Terrestrial Radio Access Network (E-UTRAN); SI Application Protocol (SlAP)". 

[13] 3GPP TS 36.314: "Evolved Universal Terrestrial Radio Access (E-UTRA); Layer 2 - 

Measurements". 

[14] 3GPP TS 36.300: " Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal 

Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2 ". 

[15] 3GPP TS 37.320: "Universal Terrestrial Radio Access (UTRA) and Evolved Universal Terrestrial 

Radio Access (E-UTRA); Radio measurement collection for Minimization of Drive Tests (MDT); 
Overall description; Stage 2". 

[16] 3GPP TS 36.423: "Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 

Application Protocol (X2AP)". 

[17] 3GPP TS 25.413: "UTRAN lu interface RANAP signalling". 

[18] 3GPP TS 48.008: "Mobile Switching Centre-Base Station System (MSC-BSS) interface; Layer 3 

specification". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TS 32.101 [1], TS 32.102 [2], TS 32.150 
[3] and TR 21.905 [4] and the following apply. A term defined in the present document takes precedence over the 
definition of the same term, if any, in TS 32.521 [5], TS 32.101 [1], TS 32.102 [2] and TR 21.905 [4], in that order. 

Target: See 3GPP TS 32.521 [5]. 

Trigger condition: See 3GPP TS 32.521 [5]. 

Hand-Over parameter Optimisation: See clause 4.3 of this document and Mobility Robustness Optimisation (MRO) 
are synonyms (see TS 36.300 [14]). 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [4], TS 32.521 [5] and the following 
apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if 
any, in TR 21.905 [4] and TS 32.521 [5]. 

CAC Composite Available Capacity 

ceo Capacity and Coverage Optimization 

CDF Cumulative Distribution Function 

COC Cell Outage Compensation 

EM Element Manager 

eNodeB, eNB evolved NodeB 

ESM Energy Saving Management 

E-UTRAN Evolved Universal Terrestrial Radio Access Network 

HO Handover 

HOO Handover parameter Optimization 

ICIC Inter Cell Interference Coordination 

IOC Information Object Class 

LB Load Balancing 

LBO Load Balancing Optimization 

MRO Mobility Robustness Optimisation 

NM Network Manager 

NRM Network Resource Model 

0AM Operation Administration Maintenance 
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RO RACH Optimization 

SON Self Organizing Networks 

UE User Equipment 

4 SON Policy and Optimization Function Definitions 

4.1 Monitoring and IVIanagement Operations for Self- 
Optimization 

4.1 .1 Monitoring and Management Function 
4.1.1.1 Usage of Itf-N 

For specifically defined Itf-N NRM Interface see clause 5. 

4.2 Load Balancing Optimization Function 
4.2.1 Objective and Targets 

The objective of LB Optimization is to cope with undesired traffic load distribution and to minimize the number of 
handovers and redirections needed to achieve the load balancing. One of the following targets or the combination of the 
following targets shall be used. The specific target value or values shall be configured by operators. Operators should 
assign weights for targets being used. 

Targets drawn from the following table can be configured for LBO: 
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Target Name 


Definition 


Legal Values 


RRC connection 
establishments 
failure rate related to 
load 


The number of Failed RRC connection establishments 
related to load/ The total number of Attempted RRC 
connection establishments. 

The target is met if the actual rate is smaller than the 
target value. 


Integer 

[0.. 100] in unit 

percentage 


E-RAB setup failure 
rate related to load 


The number of E-RAB setup failure related to load/ The 
total number of attempted E-RAB setup 

For E-RAB setup failure related to load, the causes 
"Reduce load in serving cell" and "Radio resources not 
available" defined in TS 36.413 [12] could be used. 

The target is met if the actual rate is smaller than the 
target value. 


Integer 

[0..100] in unit 
percentage 


RRC Connection 
Abnormal Release 
Rate Related to Load 


The number of abnormal RRC connection release related 
to load/ The total number of RRC connection release. 

The target is met if the actual rate is smaller than the 
target value. 


Integer 

[0..100] in unit 
percentage 


E-RAB Abnormal 
Release Rate 
Related to Load 


The number of E-RAB abnormal release related to load/ 
The total number of E-RAB release 

For E-RAB setup failure related to load, the causes 
"Reduce load in serving cell" and "Radio resources not 
available" defined in TS 36.413 [12] could be used. 

The target is met if the actual rate is smaller than the 
target value. 


Integer 

[0..100] in unit 
percentage 


Rate of failures 
related to handover 


(the number of failure events related to handover) / (the 
total number of handover events) 

The target is met if the actual rate is smaller than the 
target value. 


Integer 

[0..100] in unit 
percentage 



For the following targets out of the above table, the target values depend on the composite available capacity range in 
the cell and are defined separately for uplink and downlink. For these tuples can be configured, indicating the capacity 
ranges together with the target value valid in that range. 

RRC connection establishments failure rate related to load, 

E-RAB setup failure rate related to load, 

RRC Connection Abnormal Release Rate Related to Load, 

E-RAB Abnormal Release Rate Related to Load 

For the following targets shall be identical with the corresponding targets defined in Handover Optimization. 

Rate of failures related to handover 



4.2.2 Parameters To Be Optimized 



To reach load optimization target, LBO may optimize some mobility settings (HO and/or idle mobility configuration) 
defined in TS 36.331 [6]. 



4.2.3 Optimization Metlnod 
4.2.3.1 Problem Detection 

The problem detection is out of scope of this specification. 



£75/ 



3GPP TS 32.522 version 11.6.1 Release 11 



11 



ETSI TS 132 522 V1 1.6.1 (2013-07) 



4.2.3.2 Problem Solution 

The problem solution is out of scope of this specification. 

4.2.4 Architecture 



4.2.4.1 



Definition of Logical Functions 



LB Monitor Function: This function is used for monitoring the load balance optimization (e.g. Monitoring related 
performance counters or alarms). 

LB Policy control function: This function is used for configuring the load balance optimization policies. 

4.2.4.2 Location of Logical Functions 



NM (IRPManager) 



LB PoHcy 

Control 

Function 



DM 



LB Policy 

Control 

Function 




X2 



LB 

Monitor 

Function 



LB 

Monitor 

Function 




- Itf-N 




X2 



eNB 



EM 




For Load Balancing, the SON LB decision algorithm is located in eNB. The detailed SON functionalities in eNB are out 
of scope of this specification. 



4.2.5 



PM 



IRPManager may collect Load balancing related performance measurements. Performance Measurements related with 
Load balancing are captured in the table below: 
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Performance measurement 
name 


Description 


Related targets 


The number of Failed RRC 
connection establisliments related 
to load 


Refer to 3GPP TS 32.425 [8] 
Failed RRC connection 
establishments 


RRC connection 
establishments failure rate 
related to load 


The total number of Attempted 
RRC connection establishments 


Refer to 3GPP TS 32.425 [8] 
Attempted RRC connection 
establishments 


RRC connection 
establishments failure rate 
related to load 


The number of E-RAB setup failure 
related to load 


Refer to 3GPP TS 32.425 [8] 
Number of initial SAE Bearers 
failed to setup 


E-RAB setup failure rate 
related to load 


The total number of attempted E- 
RAB setup 


Refer to 3GPP TS 32.425 [8] 
Number of initial SAE Bearers 
attempted to setup 


E-RAB setup failure rate 
related to load 


The number of abnormal RRC 
connection release related to load 


Number of UE CONTEXT 
Release Request initiated by 
eNodeB 


RRC Connection Abnormal 
Release Rate Related to 
Load 


The total number of RRC 
connection release 


Number of Successful UE 
Context Release 


RRC Connection Abnormal 
Release Rate Related to 
Load 


The number of E-RAB abnormal 
release related to load 


Refer to 3GPP TS 32.425 [8] 
Number of SAE Bearers 
requested to release initiated 
by eNodeB per cause 


E-RAB Abnormal Release 
Rate Related to Load 


The total number of E-RAB release 


Refer to 3GPP TS 32.425 [8] 
Number of SAE Bearers 
successfully released 


E-RAB Abnormal Release 
Rate Related to Load 


the number of failure events 
related to handover 


Refer to 4.3.5 


Rate of failures related to 
handover 


the total number of handover 
events 


Refer to 4.3.5 


Rate of failures related to 
handover 



NOTE: The monitoring of performance measurements will make use of existing PM IRP. 

4.3 Handover (HO) Parameter Optimization Function 
4.3.1 Objective and Targets 

For intra-LTE, one of the following targets or the combination of the following targets shall be used. The specific target 
value shall be configured by operators. Operators should assign weights for targets being used. 



Target Name 


Definition 


Legal Values 


Rate of failures related to 
handover 


(the number of failure events related to handover) / (the total 
number of handover events) 

The target is met if the actual rate is smaller than the target value. 


Integer 

[0..100] in unit 
percentage 



The objective of minimizing the number of unnecessary handovers shall always be pursued in case the other target/s 
configured by the operator is/are achieved. This objective may not need configuration of a target value. 



4.3.2 Parameters To Be Optimized 

The tables below summarise the handover parameters in TS 36.331 [6]. 
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Table 4.3.2-1 . Handover parameters that may be optimized for intra-frequency and inter-frequency 

handovers 



Event 


Summary 


Tunable parameters 


A3 


Neighbour becomes offset better than serving 


Ofn, Ofs, Ocn, Ocs, Hys, Off, timeloTrigger 


A4 


Neighbour becomes better than threshold 


Ofn, Ocn, Hys, Thresh, Off, timeToTrigger 


A5 


Serving becomes worse than thresholdl and 
neighbour becomes better than threshold2 


Ofn, Ocn, Hys, Threshi, Thresh2, Off, 
timeToTrigger 



Table 4.3.2-2. Handover parameters that may be optimised for inter RAT handover 



Event 


Summary 


Tunable parameters 


B1 


Inter RAT Neighbour becomes better than 
threshold 


Ofn, Hys, Thresh, timeToTrigger 


B2 


Serving becomes worse than thresholdl and 
inter RAT neighbour becomes better than 
threshold2 


Ofn, Hys, Threshi, Thresh2, timeToTrigger 



4.3.3 Optimization Metliod 



4.3.3.1 



Problem Detection 



HO Parameter Optimization Function shall focus on detecting the problem scenarios described in TS 32.521 [5]; 
namely: too early handovers, too late handovers and inefficient use of NW resources due to HOs. For more 
information about these scenarios see TS 32.521 [5] section 6.1.3. 

The following inputs may be used for the identification of the problem scenarios: 

Event capture and analysis 

UE measurements 

Performance measurements 

In event capture and analysis, the eNodeB exploits event information associated with a UE context, such as evidence of 
previous handovers (UE History, see TS 36.423 [7]) and HO failure details (such as in which cell the handover failed 
and where the UE re-established the connection). 

UE measurements are sent within UE measurement reports and they may indicate whether HOs are too early or too late. 

HO-related performance measurements (PMs) collected at the source and / or target eNB can be useful in detecting HO- 
related issues on the cell level. Since the impact of incorrect HO parameter setting will also be on the cell-level, PMs 
can provide useful information that can be used to detect and resolve HO-related issues due to incorrect parameter 
settings. 



4.3.3.2 



Problem Solution 



HO Parameter Optimization Function will aim at optimizing the HO parameters listed in Section 4.3.2 in such way to 
mitigate the problem scenarios discussed in Section 4.3.3.1. The optimization algorithms will not be specified. The 
exact set of HO parameters that may be adjusted by the algorithms is dictated by the choice of triggered HO 
measurements made by the RRM entity in an eNodeB. 

4.3.4 Arcinitecture 



4.3.4.1 



Definition of Logical Functions 



HO Parameter Optimization Monitor Function: This function is used for monitoring the handover parameter 
optimization (e.g. monitoring related performance counters or alarms). 
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HO Parameter Optimization Policy Control Function: This function is used for configuring the handover parameter 
optimization poHcies. 

4.3.4.2 Location of Logical Functions 

For Handover (HO) parameter optimization there are several options for the location of the SON algorithm: 

1 . The SON algorithm is located in the eNB(s). 

2. The SON algorithm is located in the EM, the parameter changes are executed in the eNBs. 
An example for the first option is shown in figure 4.3.4.2: 
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Figure 4.3.4.2: Example when the SON algorithm is located in the eNB(s) 

The detailed SON functionalities in eNB are out of scope of this specification. 

4.3.5 PM 

IRPManager shall collect HO-related performance measurements from the source and / or target eNB which can be 
useful in detecting HO-related issues on the cell level. The following input can be used for the identification of the 
problem scenarios specified: 

The number of RLE event happened within an interval after handover success. 

The number of unnecessary handovers to another RAT without RLE. 

Performance Measurements related to handover failure are captured in the table below. 

The Performance Measurements are for outgoing handovers. Eurther, they should be available on a cell relation basis. 
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Performance measurement 
name 


Description 


Related targets 


Number of handover events 


Includes successful handovers 
plus all identified failures 


Rate of failures related to 
handover 


Number of HO failures 


All failure cases 


Rate of failures related to 
handover 


Number of too early HO failures 


Too early HO failure cases 


Rate of failures related to 
handover 


Number of too late HO failures 


Too late HO failure cases 


Rate of failures related to 
handover 


Number of HO failures to wrong 
cell 


HO failures to wrong cell 


Rate of failures related to 
handover 


Number of unnecessary HOs to 
another RAT 


Unnecessary HOs to each of 
different RATs 





NOTE: The monitoring of performance measurements will make use of existing PM IRP. 



4.4 



Interference Control Function 



4.5 Capacity and Coverage Optimization Function 

4.5.1 Objective and Targets 

The objective of capacity and coverage optimization is to provide optimal coverage and capacity for the radio network. 
A tradeoff between capacity and coverage needs to be considered. 

The detailed target(s) FFS. 

4.5.2 Parameters to be optimized 

To reach capacity and coverage optimization targets, the following parameters may be optimized: 

• Downlink transmit power 

• Antenna tilt 

• Antenna azimuth 

4.5.3 Optimization Method 



4.5.3.1 



Problem Detection 



The main symptoms of capacity and coverage optimization problems (see TS 37.320 [15]) are: 

Coverage hole: A coverage hole is an area where the pilot signal strength is below a threshold which is required by a 
UE to access the network, or the SINRs of both serving and neighbor cells is below a level needed to maintain the basic 
service. Coverage holes are usually caused by physical obstructions such as new buildings, hills, or by unsuitable 
antenna parameters, or just inadequate RF planning. UE in coverage hole will suffer from call drop and radio link 
failure. Typical phenomenon of coverage hole is either HO failure happens frequently and cannot be optimized by HO 
parameter optimization or call drop happens frequently and cannot be rescued by RRC re-establishment. 

Weak coverage: Weak coverage occurs when the pilot signal strength or the SNR (or SINR) of serving cell is below 
the level needed to maintain a planned performance requirement (e.g. cell edge bit-rate). 

Pilot pollution: In areas where coverage of different cells overlap a lot, interference levels are high, power levels are 
high, energy consumption is high and cell performance may be low. Typically in this situation UEs may experience 
high SNR to more than one cell and high interference levels. 
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Overshoot coverage: Overshoot occurs when coverage of a cell reaches far beyond what is planned. It can occur as an 
"island" of coverage in the interior of another cell, which may not be a direct neighbor. Reasons for overshoot may be 
reflections in buildings or across open water, lakes etc. UEs in this area may suffer call drops or high interference. 

DL and UL channel coverage mismatch: DL channel coverage is larger than UL channel coverage is one typical 
scenario of DL and UL channel coverage mismatch. The UE will suffer UL problems when it moves into the mismatch 
area. 

In a realistic network, these symptoms may be tolerated to a certain level. These symptoms may indicate a real problem 
when combined with other factors such as frequency of symptoms, duration of symptoms, or affected population. 



The following inputs may be used for the identification of the problem scenarios: 

• UE measurements 

• Performance measurements 

• Alarms, other monitoring information e.g. trace data 

UE measurements are sent within UE measurement reports and they may indicate the capacity and coverage problem. 

Capacity and coverage related performance measurements collected at the source and / or target eNB can be useful in 
detecting capacity and coverage related issues on the cell level. Minimizing Driver Test (MDT) or HO-related 
performance measurements may be used also in detecting capacity and coverage related issues on the cell level. 

Alarms, other monitoring information e.g. trace data can be correlated to get an unambiguous indication of capacity and 
coverage problem. 

4.5.3.2 Problem Solution 

Capacity and coverage optimization function will aim at optimizing the parameters listed in Section 4.5.2 in such way 
to mitigate the problem scenarios discussed in Section 4.5.3. L 

4.5.4 Architecture 

4.5.4.1 Definition of Logical Functions 

ceo Monitor Function: This function is used for monitoring the capacity and coverage optimization (e.g. monitoring 
related performance counters, UE measurements or alarms). 

ceo Policy Control Function: This function is used for configuring the capacity and coverage optimization policies. 

4.5.4.2 Location of Logical Functions 

For capacity and coverage optimization (CCO), there are several options for the location of the centralized CCO SON 
algorithm: 

1 . The CCO SON algorithm is located in the DM. The capacity and coverage optimization decision is made by 
the DM centralized CCO algorithm. 

2. The CCO SON algorithm is located in the NM. The capacity and coverage optimization decision is made by 
the NM centralized CCO algorithm. 

An example for the first option is shown in figure 4.5.4.2: 
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Figure 4.5.4.2: Example when the CCO SON algorithm is located in DM 

The detailed CCO SON algorithm in OAM (NM centralized or EM centralized) is out of scope of this specification. 



4.5.5 



PM 



The IRP Agent shall support a capability allowing the IRPManager to collect CCO related performance measurements to 
know the situation of coverage or interference which may then trigger corresponding optimization procedures. 
Performance measurements related with CCO are captured in the table below: 



Performance measurement 
name 


Description 


Comment 


Maximum carrier transmit power 


Refer to 3GPP TS 32.425 [8] 
IVIaximum value of the total carrier 
power transmitted in a cell. 




IVlean carrier transmit power 


Refer to 3GPP TS 32.425 [8] 
Mean value of the total carrier power 
transmitted in a cell. 





4.6 RACH Optimization Function 
4.6.1 Objective and Targets 

The objective of RACH Optimization is to automatically set several parameters related to the performance of RACH. 
One of the following targets shall be used. The specific target value shall be configured by operators. 
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Target Name 


Definition 


Legal Values 


Access Probability, 
AP 


The probability that the UE has access after a certain 
random access attempt number. 

The target is met if the actual access probability is higher 
than the target probability value. 


CDF of access 
attempts. See 
section 5.5.1 


Access Delay 
Probability, ADP 


The probability distribution of Access Delay expected to be 
experienced by UEs accessing the RACH Channel. 

The target is met if the actual access probability is higher 
than the target probability value. 


CDF of delays. 
See section 
5.5.1 



4.6.2 Parameters to be optimized 



To achieve RACH optimization target, RACH optimization function may optimize several parameters defined in TS 
36.300 [14] section 22.4.3. 

4.6.3 Optimization Metinod 

4.6.3.1 Problem Detection 

The problem detection is out of scope of this specification since the RACH optimization entity resides in the eNB. 

4.6.3.2 Problem Solution 

The problem solution is out of scope of this specification since the RACH optimization entity resides in the eNB. 

4.6.4 PM 

The IRP Agent shall support a capability allowing the IRPManager to collect RACH optimization related performance 
measurements. Performance measurements related with RACH optimization are captured in the table below: 



Performance measurement 
name 


Description 


Related targets 


Distribution of RACH preambles 
sent 


Refer to 3GPP TS 32.425 [8] 
Cumulative Distribution of 
RACH preambles sent by UE 


Access Probability, AP 


Distribution of RACH access delay 


Refer to 3GPP TS 32.425 [8] 
Cumulative Distribution of 
RACH Access Delay 


Access Delay Probability, 
ADP 



4.7 



SON coordination 



4.7.1 



Introduction 



There may be conflicts or dependencies between SON functions; SON coordination means preventing or resolving 
conflicts or negative influences between SON functions to make SON functions comply with operator's policy. 

As the example shown in figure 4.7.1.1, there is mesh relationship between SON functions and network parameters (or 
network elements) in which conflicts or negative influences may happen if no SON coordination. 
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Figure 4.7.1.1 : Mesh relationship between SON functions and network parameters (or network 

elements) 

4.7.2 CoorcJination between SON functions below Itf-N and non-SON CM 
operations over itf-N 

4.7.2.1 Description 

Conflict may arise between non-SON CM operation via Itf-N and the SON functions (in particularly self-optimization 
function) below Itf-N in the following scenario. 

The network parameters can be changed by the non-SON CM operations via ltf-N,meanwhile, the SON functions below 
Itf-N may also require changing the parameters. If these parameters are some (same or associated) parameters of some 
(same or associated) nodes which will be changed by the non-SON CM operations and the SON functions below Itf-N, 
conflict arises. (Conflict see clause 4 of 32.521 [5]) 

For example, the non-SON CM operation via Itf-N may try to reduce the CIO (cell individual offset) parameter, it 
makes the HO trigger between cells (e.g., HO from cell A to cell B) become more difficult. But in the meanwhile, the 
SON function MRO may try to increase the CIO parameter, it makes the HO easier. In this case, if the conflict is not 
coordinated, the parameter may be modified twice. Then the failed rate related with handover may rise or ping-pong 
handover may arise between the two cells. 

In case the SON function below Itf-N and non-SON CM operation via Itf-N has conflict, the SON function below Itf-N 
shall take into account and re-evaluate, if applicable, any non-SON CM operation changes via Itf-N. 

As showing in the following example. At Time T3, after Non-SON operation has finished the modification, SON 
function below Itf-N shall take the non-SON CM operation changes into account for further SON analysis. 
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4.7.2.2 Prevention 

In a real network, it is possible that non-SON CM operations via Itf-N and several SON functions below Itf-N are 
running at the same time, and they may try to change the same or associated parameters during a short time period. So 
coordination is needed to prevent this kind of conflicts. 

4.7.2.3 Resolution 

Refer to common coordination solutions part. 



4.7.3 Coordination between different SON functions 

Note: The coordination between different SON functions should be decided case by case. 

4.7.3.1 Coordination between Cell Outage Compensation and Energy Saving 

Management 

4.7.3.1.1 Description 

A conflict could arise between energy saving and cell outage compensation in the following scenario. 

One or more candidate cells are configured to possibly take coverage of the original cell. The original cell is in 
energySaving state or is about to enter energySaving state. One or more candidate cells go into outage with the 
consequence that coverage of the original cell can not be provided any more. 



4.7.3.1.2 



Prevention 



Prevention is hardly possible, except making the cells as outage proof as possible. But cell outages can happen even to 
the most stable cell in a network. 

4.7.3.1.3 Resolution 

If the original cell is in energySaving state, it shall leave energySaving state. 

If the original cell is about to enter energySaving state, it shall not go into energySaving state until candidate cell outage 
is recovered and candidate cell is able to provide the coverage. 
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The original cell may go into the energySaving state after the candidate cell outage is recovered and coverage of the 
original cell can be taken over by candidate cell again. 

4.7.3.2 Coordination among Cell Outage Compensation, Capacity and Coverage 

Optimization, and Energy Saving Management 

4.7.3.2.1 Description 

Capacity and Coverage Optimization (CCO), Cell Outage Compensation (COC) and Energy Saving Management 
(ESM) may require changes to the coverage and/or capacity of one or more cells during the same time period, which 
could lead to the following issue: 




Figure 4.7.3.2 Coordination among COC, CCO, and ESM 

Figure 4.7.3.2 is a typical scenario for the coordination among COC, CCO and ESM. 

Cell 1 is detected in outage, COC will try to compensate the outage Cell 1 by reconfiguring the RF configuration of 
some compensation candidate cells, e.g., TX power, antenna tilt and antenna azimuth of Cell 2 and Cell 3. 

Before the outage Cell 1 is compensated, CCO may detect the degrading of coverage related KPI (e.g., success rate of 
RRC connection establishments, cell throughput) of Cell 1 and its neighbour cells (Cell 2 and other blue cells) and 
make a conclusion that there is a coverage problem in this KPI degraded area. 

Meanwhile, ESM is operating on Cell 2 to compensate the coverage of its neighboring cell (Cell 4) which is going into 
energySaving state. 

From the time point at which the outage Cell 1 is detected until Cell 1 has been compensated by Cell 2 and Cell 3, 
during this period, if there is no coordination among COC, CCO and ESM, there will be possibly different settings for 
adjusting TX power, antenna tilt and antenna azimuth of Cell 2 for COC, CCO or ESM purposes respectively. It's most 
likely that the adjustment from COC, ESM and optimization from CCO may conflict in the common affected outage 
compensation candidate cell(s) (Cell 2 in the above example). 

It is also possible that ESM is operating on Cell 2 to compensate the coverage of Cell 4 that is in energySaving state, 
while COC detects that Cell 1 has outage, and requests Cell 2 to compensate the coverage of Cell 1 . COC and ESM 
need to be coordinated to determine if this request can be accepted. 

After the outage cell comes back to normal, the COC exits the coordination scenario, while CCO and ESM continute to 
work and need to be well coordinated. For example, CCO may adjust the antenna tilt of Cell 2 in a downward direction 
to improve the coverage signal quality, but ESM may adjust the antenna tilt of Cell 2 in an opposite direction to enlarge 
its coverage area for purpose of ES compensation. Therefore, coordination should be continued between CCO and ESM 
to resolve the possible configuration conflict on Cell 2. 

Other conflict scenarios could be: 

Cell A is compensating to provide coverage for Cell B that is in energySaving state. COC detects that Cell A has 
outage. Since Cell A is not able to provide the coverage for Cell B any more. Cell B needs to be covered by another 
cell, or to deactivate energy saving. 
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Cell A is in energySaving state. COC detects Cell B has outage, and requests Cell A to compensate the coverage of Cell 
B. Cell A may need to terminate energy saving in order to compensate the coverage of Cell B. 

Cell A which is compensating Cell B in outage shall not go into energySaving state as long as its compensation for Cell 
B is needed. 

4.7.3.2.2 Prevention 

Prevention is hardly possible. 

4.7.3.2.3 Resolution 

Refer to clause 4.7.4 General SON coordination solutions. 

4.7.3.3 Coordination between Cell Outage Compensation and Automatic Neighbour 
Relation 

4.7.3.3.1 Description 

In case one cell is detected in outage, COC will try to compensate the outage cell by reconfiguring the RF configuration 
of some compensation candidate cells. As a result of this, there will be new NRs (neighbour relations) which reflect the 
new topology relations. 

For a stable network, ANR could be deactivated for the purpose of system resource saving. If ANR is deactivated, the 
new NRs cannot be captured in NRT by ANR. Network performance, for example, handover will be impacted 
negatively by the NRT which lacks of the new NRs. 

4.7.3.3.2 Prevention 

Prevention is hardly possible, except making the cells as outage proof as possible. But cell outages can happen even to 
the most stable cell in a network. 

4.7.3.3.3 Resolution 

The ANR function should monitor if a cell outage or cell outage compensation takes place within its area. If this 
happens, then the ANR function should check the NRs of the affected cells (for example the outage cell and its 
neighbours and neighbours' neighbours). In case the ANR function in the the affected area is deactivated, the possible 
NRs change of the affected cells should be taken as a factor to reactivate the ANR function. 

4.7.3.4 Coordination between Handover parameter Optimization and Load 
Balancing Optimization 

4.7.3.4.1 Description 

HOO function and LBO function both optimize network performance by adjusting handover parameters such as CIO, 
Hysteresis, TTT, etc. Conflicts may happen when HOO function and LBO function are changing the same or associated 
handover parameters in opposite direction or towards the same direction but on different scales. 

For example, HOO function may adjust handover parameters (e.g. decrease CIO of source cell A to target cell B) to 
minimize the number of too early handovers from cell A to cell B whilst LBO function may adjust handover parameters 
(e.g. increase the CIO of source cell A to target cell B) to make the handover from cell A to cell B more easier in case 
the load of cell B is much less than cell A. 

4.7.3.4.2 Prevention 

Prevention is hardly possible unless switch off HOO function or LBO function. However, disabling the complete HOO 
function or LBO function cannot fulfil the requirement that both handover performance and load performance need to 
be improved at the same time. 
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4.7.3.4.3 Resolution 

For the coordination between HOO and LBO, IRPManager should assign priorities for HOO function and LBO function 
or weights for targets of HOO function and LBO function according to operator's policy. 

The policy should cover different scenarios well: 

• Policy may assign higher priority for HOO function than LBO function or higher weight for target of HOO function 

than targets of LBO function when resolving MRO issues (HO too early/too late/to wrong cell) is the main 
objective of network optimization, e.g. in handover optimization scenario for better coverage. 

• Policy may assign lower priority for HOO function than LBO function or lower weight for target of HOO function 

than targets of LBO function when enhancing load performance is the main objective of network optimization, e.g. 
in load optimization scenario for better capacity. 

Concrete way of using priority or weights of targets, refers to clause 4.7.4 General SON coordination solutions. 



4.7.4 General SON coordination solutions 
4.7.4.1 Overview 

As described in TS 32.521 [5], multiple SON functions may have conflicting demands on network resources. This 
situation is considered as "SON functions in conflict" and requires conflict prevention or resolution. A SON 
Coordination Function will be responsible for preventing or resolving conflicts. 

Conflict needs to be detected when there is "SON functions in conflict". Policies can be preset by operator to SON 
Coordination Function to avoid conflict on certain associated resources (network elements and/or parameters) among 
SON functions. 

Conflict prevention is to take some advanced methods to prevent the occurrence of conflict. However, no matter what 
implementation is chosen, it is impossible to guarantee that 100% of conflicts will be prevented, so conflict detection 
and resolution are needed. Conflict detection should be taken firstly as the pre-condition of conflict resolution. 

The SON Coordination Function is a logical function, which means it can be implemented as a separate function entity 
or as part of SON function. 

When the SON Coordination Function is implemented as a separate function entity, all the SON functions send the 
necessary information to the SON Coordination Function, the SON Coordination Function coordinate these SON 
functions as a centralized control point. This centralized coordination approach fulfills the requirements of SON 
coordination in a large area scope, for example, the coordination between NM centralized SON functions and 
distributed SON functions. 

In some other situations, coordination is only needed in a smaller area, for example, the coordination between 
distributed SON functions inside one domain. Then the SON Coordination Function can be implemented as part of each 
SON function. The necessary coordination information can be inter-exchanged between each SON functions to achieve 
coordination as well. 

The SON Coordination Function may reside above or below Itf-N. Figure 4.7.4.1 shows an example of a SON 
Coodination Function, which is a separate function entity, above Itf-N. 
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Figure 4.7.4.1: Example of SON Coordination entity located in NM 

The SON Coordination Function may be responsible for conflict prevention, conflict resolution, or both in parallel. 



4.7.4.2 



Conflict prevention 



To prevent conflicts between the SON functions, the SON functions may ask the SON Coordination function for 
permission before changing some specific configuration parameters. The SON Coordination Function should check the 
SON coordination interdependancy policy between this requesting SON function and other SON function(s) upon 
receiving the permission request from the SON function. SON coordination interdependancy policy which is pre- 
configured can help the SON Coordination Function to find which SON function(s) possibly conflict with this 
requesting SON function. 

As a basis for decisions, the SON Coordination Function will typically use one or some of the following inputs received 
from the SON function(s) 

Which SON functions are modifying configuration parameters (including information about vendor, release etc.) 

Configuration parameters intended to be changed and/or their existing and proposed new values 

The time duration how long the configuration parameter should not be interfered with ("impact time") 

The state of SON functions 

The SON targets which are the justification for the configuration change. 

Possible impact of a parameter change on other objects ("impact area") 

The state of certain managed objects 

Possible impact of the parameter change on Key Performance Indicators 

Priority of SON functions, which can be used to determine the execution order of requests from different SON 
functions in case of conflicts 

SON coordination policies 
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The SON Coordination Function sends the decision back to the requesting SON function; the decision may be 
confirmation or suspension or rejection of the SON executing request, or other actions like configuration of specific 
parameters with specific value. 

After SON function executes action, the SON Coordination Function is then informed about the result 
(successful/unsuccessful, parameters changes) of the executed SON action. 

The SON Coordination Function may prevent parameter changes by one or more SON functions for a specified time 
period after the same parameter has been changed by another SON function. 

The SON Coordination Function may inform a SON Function of a managed object state change which may impact 
calculation of KPIs. 

Detailed description of how to use general SON coordination solutions are in Annex B. 



4.7.4.3 Conflict resolution 

The SON Coordination Function should detect conflicts and attempt to resolve the conflicts. 

To detect conflicts, the SON Coordination Function will typically analyse one or some of the following types of data 

• Key Performance Indicators which indicate if SON functions are meeting their targets or improving network 
performance 

• Measurements which indicate if SON functions are meeting their targets or improving network performance 

• Unacceptable oscillations in configuration parameters 

To resolve conflicts, the SON Coordination Function will typically use one or some of following methods 

• Enabling/disabling/suspending certain SON functions 

• Stopping/suspending/modifying certain SON actions 

• Modifying certain configuration parameters 
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5 Information Object Classes (lOCs) 

5.1 Information entities imported and local labels 



Label reference 


Local label 


3GPP TS 32.622 [9], IOC, Top 


Top 


3GPP TS 32.622 [9], IOC, SubNetwork 


SubNetwork 


3GPP TS 32.762 [10], IOC, ENBFunction 


ENBFunction 


3GPP TS 32.762 [10], IOC, EUtranRelation 


EUtranRelation 


3GPP TS 32.762 [10], IOC, EUtranGenericCell 


EUtranGenericCell 



5.2 Class diagram 

5.2.1 Attributes and relationships 
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SONTargets 


1 0..1 



















NOTE 1: IOC SONControl shall be instantiated whenever one or more IOC SONTargets are instantiated. 

Figure 5.2.1-1 : Cell view of SON Policy NRM 
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Figure 5.2.1-2: ES Policies NRM lOCs (Containment Relationship) 

NOTE 2: Also IOC SONControl is used for intra-LTE ES purposes - see clause 5.3.2.2 - but is not shown in Figure 
5.2. 1-2 to avoid the impression that there would an additional instance of this IOC be needed for intra- 
LTE ES. 
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Figure 5.2.1-3: lOCs to control SON on cell level (Containment Relationship) 
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JL 



«lnformationObjectClass» 
Subnetwork 

(from TS 32.622) 



♦ 1 
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\ /0-n 



«lnformationObjectClass» 
ManagedElement 

(from TS 32.622) 



♦ 1 
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es» 



«lnformationObjectClass» 
ENBFunction 

(from TS 32.762) 
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ss» 



\ /0--" 

«lnformationObjectClass» 
EUtranGenericCell 

(from TS 32.762) 
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0..1 



«lnformationObjectClass» 
InterRatEs Policies 





«names» 




«lnformationObjectClass» 
InterRatEsPolicies 






0..1 


1 









«names» 




«lnformationObjectClass» 
InterRatEsPolicies 






0..1 


1 







Figure 5.2.1-4: Inter-RAT ES Policies NRM lOCs (Containment Relationship, part 1) 

NOTE 3: Also IOC SONControl is used for inter-RAT ES purposes - see clause 5.3.2.2 - but is not shown in Figure 
5.2.1-4 to avoid the impression that there would an additional instance of this IOC be needed for inter-RAT ES. 
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«ncmes» 



\/ 



«lnformationObjectClass>:|> 
Subnetwork 

(fromTS 32.622) 



1 



«names» 



— >| 
0..1 



«lnformationObjectClass» 
InterRatEs Policies 



«naiT 



es» 



\/0..n 



«lnformationObjectClass>; 
External EN BFunction 

(fromTS 32.762) 



«nam 



1 
es» 
\/0..n 



«lnformationObjectClass>; 
External EUtranGenericCell 

(fromTS 32.762) 



«names» 



«names» 



0..1 



«lnformationObjectClass>; 
-^ InterRatEs Policies 



0..1 



«lnformationObjectClass>; 
-^ InterRatEs Policies 



Figure 5.2.1-5: Inter-RAT ES Policies NRM lOCs (Containment Relationship, part 2) 
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« iames» 



^' 



«lnformationObjectClass» 
Subnelwork 

(fromTS 32.622) 



«names» 



-^ 



0..1 



«lnformationObjectClass» 
InterRatEs Policies 



«names» 



\/0..n 



«lnformationObjectClass» 
IVIanaged Be ment 

(fromTS 32.622) 



TT 



«names» 



ISUL. 



«lnformationObjectClass» 
RncFunction 

(fromTS 32.642) 



«names» 



-^ 



0..1 



«lnformationObjectClass» 
InterRatEs Policies 



«names» 



isuL. 



«lnformationObjectClass» 
UtranGenericCell 

(fromTS 32.642) 

1 — 



«nanies» 



-> 



0..1 



«lnformationObjectClass» 
InterRatEs Policies 



Figure 5.2.1-6: Inter-RAT ES Policies NRM lOCs (Containment Relationship, part 3) 

NOTE 4: Also IOC SONControl is used for inter-RAT ES purposes - see clause 5.3.2.2 - but is not shown in 
Figures .2. 1-6 to avoid the impression that there would an additional instance of this IOC be needed for inter-RAT ES. 
SONControl is contained by Subnetwork or RncFunction when esSwitch attribute is applied in SONControl. 
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«names» 



\1 

«lnformationObjectClass> 
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(from TS 32.622) 



T 
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\ /0-n 
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1 
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-9» InterRatEsPolicies 
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«lnformationObjectClass> 
txternalUtranGenericCell 

(from TS 32.642) 



«names» 



«lnformationObjectClass> 
»> InterRatEsPolicies 



0..1 



Figure 5.2.1-7: Inter-RAT ES Policies NRIVI lOCs (Containment Relationship, part 4) 
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«lnformationObjectClass» 
ManagedElement 

(from TS 32.622) 
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1 




0..1 
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«lnformationObjectClass» 
BtsSiteMgr 
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VO..n 

«lnformationObjectClass» 
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(from TS 32.652) ♦" 

1 
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— ^ 
0..1 



«lnformationObjectClass» 
InterRatEsPolicies 



— > 
0..1 



«lnformationObjectClass» 
InterRatEsPolicies 



Figure 5.2.1-8: Inter-RAT ES Policies NRM lOCs (Containment Relationship, part 5) 
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«names» 



\1 

«lnformationObjectClass> 
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(from TS 32.622) 
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«lnformationObjectClass> 
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Figure 5.2.1-9: Inter-RAT ES Policies NRIVI lOCs (Containment Relationship, part 6) 
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Subnetwork 
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5.2.2 



Figure 5.2.1-10: lOCs for SON coordination (Containment Relationship) 

Inheritance 



«lnformationObjectGlass» 
Top 

(from TS 32.622) 





«lnformationObjectClass» 
SONTargets 



«lnformationObjectClass» 
SONControl 
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Figure 5.2.2-1 : SON Policy NRIUI Inheritance Hierarchy 



«lnformationObjectClass» 
Top 

(from TS 32.622) 




«lnformationObjectClass» 
ESPolicies 



«lnformationObjectClass» 
InterRatEs Policies 



Figure 5.2.2-2: ES Polices NRIVI lOCs (Inheritance Relationship) 



«lnformationObjectClass» 
Top 

(from TS 32.622) 



«lnformationObjectClass» 
EUtranCellSON 



Figure 5.2.2-3: Inheritance for IOC to control SON on cell level 



«lnformationObjectClass» 
Top 

(from TS 32.622) 



«lnformationObjectClass>5' 
EnergySavingProperties 



Figure 5.2.2-4: Energy saving properties NRM lOCs (Inheritance Relationship) 
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«lnformationObjectClass» 
Top 

(from TS 32.622) 



«lnformationObjectClass» 
SONFunclnfo 



«lnformationObjectClass» 
SONCoordinationPolicies 



Figure 5.2.2-5: lOCs for SON coordination (Inheritance Relationship) 



5.3 Information Object Class (IOC) (definitions 



5.3.1 SONTargets 



5.3.1.1 Definition 

This IOC represents targets for SON functions and their relative weights. 

Target hierarchy rule: 

An NRM IOC instance X may name-contain an IOC SONTargets instance T. The rule states that: 

If X name-contains a SONTargets instance T, then T is applicable to X. 

If X and all its superior instances do not name-contain any SONTargets instance, then no SONTargets instance is 
applicable to X. 

If X does not name-contain any SONTargets instance, but one or more of X's superior instances name -contain a 
SONTargets instance, then the SONTargets instance of the superior instance closest to X, in X's naming tree, is 
applicable to X. 



5.3.1.2 



Attributes 



Attribute name 


Support 
Qualifier 


Read 
Qualifier 


Write 
Qualifier 


hoFailureRate 


0*) 


M 


M 


rrcConnectionEstablishmentFailureRateCharact eristic 


0*) 


M 


M 


rrcConnectionAbnormalReleaseRateCharacteristic 


0*) 


M 


M 


eRabSetupFailureRateCharacteristic 


0*) 


M 


M 


eRabAbnormalReleaseRateCharacteristic 


0*) 


M 


M 


rachOptAccessProbability 


CM**) 


M 


M 


rachOptAccessDelayProbability 


CM**) 


M 


M 



*) Note 1 : At least one of the attributes shall be supported. 
**) Note 2: Only one of these attributes shall be present. 
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5.3.1.3 



Attribute constraints 



Name 


Definition 


rachOptAccessProbability CM 
Support Qualifier 


RACH Qptimization is supported and Access Probability is 
supported as target. 


rachOptAccessDelayProbability 
Cl\/1 Support Qualifier 


RACH Qptimization is supported and Access Delay 
Probability is supported as target. 



5.3.1.4 



Notifications 



The common notifications defined in subclause 5.6.1 are valid for this IOC, without exceptions or additions. 

5.3.2 SONControl 



5.3.2.1 



Definition 



This IOC represents the possibility to switch on or off SON functions. This is provided for Handover parameter 
optimization, Load Balancing optimization. Energy Saving, RACH optimization and Cell Outage Compensation. 



5.3.2.2 



Attributes 



5.3.2.3 



Attribute name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


hooSwitch 


CM 


M 


M 


IboSwitch 


CM 


M 


M 


esSwitch 


CM 


M 


M 


roSwitch 


CM 


M 


M 


cocSwitch 


CM 


M 


M 



Attribute constraints 



5.3.2.4 



Name 


Definition 


hooSwitch CM Support 
Qualifier 


Handover (HQ) parameter Optimization function is supported. 


IboSwitch CM Support 
Qualifier 


Load Balancing Optimization function is supported. 


esSwitch Support 
Qualifier 


The condition is "Distributed or EM-Centralized ESM architecture is 
supported". 


roSwitch CM Support 
Qualifier 


RACH Optimization is supported. 


cocSwitch Support 
Qualifier 


The condition is "CoC is supported". Only allowed to be present, if 
SONControl is contained in subnetwork IOC instance. 



Notifications 



The common notifications defined in subclause 5.6.1 are valid for this IOC, without exceptions or additions. 

5.3.3 ESPolicies 



5.3.3.1 



Definition 



This IOC represents the energy saving policies information. This object class is valid in a distributed ES architecture or 
in an EM-centralized ES architecture. 



5.3.3.2 



Attributes 



Attribute name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


esActivationOriginalCellLoadParameters 


CM 


M 


M 


esActivationCandidateCellsLoadParameters 


CM 


M 


M 


esDeactivationCandidateCellsLoadParameters 


CM 


M 


M 


esNotAllowedTimePeriod 


O 


M 


M 
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5.3.3.3 



Attribute constraints 



Name 


Definition 


esActivationOriginalCellLoadParameters 


The condition is "Intra-RAT ESIVI is supported AND 
the cell acts as an original cell". 


esActivationCandidateCellsLoadParameters 


The condition is "Intra-RAT ESIVI is supported AND 
the cell acts as a candidate cell". 


esDeactivationCandidateCellsLoadParameters 


The condition is "Intra-RAT ESM is supported AND 
the cell acts as a candidate cell". 



5.3.3.4 Notifications 

The common notifications defined in subclause 5.6.1 are valid for this IOC, without exceptions or additions. 

5.3.4 EUtranCellSON 
5.3.4.1 Definition 

This IOC represents the parameters for control of SON functions on E-UTRAN cell level. 



5.3.4.2 



Attributes 



Attribute name 


Support 
Qualifier 


Read 
Qualifier 


Write 
Qualifier 


maximumDeviationHoTrigger 


CM 


M 


M 


minimumTimeBetweenHoTriggerChange 


CM 


M 


M 



5.3.4.3 



Attribute constraints 



Name 


Definition 


maximumDeviationHoTrigger Support 
Qualifier 


The condition is "HOG function is supported". 


minimumTimeBetweenHoTriggerChange 
Support Qualifier 


The condition is "HOG function is supported". 



5.3.4.4 Notifications 

The common notifications defined in subclause 5.6.1 are valid for this IOC, without exceptions or additions. 

5.3.5 Void 

5.3.6 EnergySavingProperties 



5.3.6.1 



Definition 



This IOC represents the energy saving properties of a network element supporting Energy Saving Management 
functionality. 
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5.3.6.2 Attributes 



Attribute name 


Support 
Qualifier 


Read 
Qualifier 


Write Qualifier 


energySavingState 


M 


M 


- 


energySavingControl 


CM 


M 


M 


isProbingCapable 





M 


- 



5.3.6.3 



Attribute constraints 



Name 


Definition 


energySavingControl CM 
Support Qualifier 


The condition is "ESIVI functionality supports and uses NIVI- 
Centralized architecture". 



5.3.6.4 Notifications 

The common notifications defined in subclause 5.6.1 are valid for this IOC. Notification notify Attribute ValueChange 
shall be supported for attribute energySavingState. 

5.3.7 InterRatEsPolicies 



5.3.7.1 



Definition 



This IOC represents the inter-RAT energy saving policies information. This object class is valid in a distributed ES 
architecture or in an EM-centralized ES architecture. 



5.3.7.2 



Attributes 



Attribute name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


interRatEsActivationOriginalCellParameters 


CM 


M 


M 


interRatEsActivationCandidateCell Parameters 


CM 


M 


M 


interRatEsDeactivationCandidateCell Parameters 


CM 


M 


M 



5.3.7.3 



Attribute constraints 



Name 


Definition 


interRatEsActivationOriginalCellParame 
ters CM Support Qualifier 


The condition is "The cell acts as an original cell" 
AND inter-RAT ESM is supported. 


interRatEsActivationCandidateCellParam 
eters CM Support Qualifier 


The condition is "The cell acts as a candidate cell" 
AND inter-RAT ESM is supported. 


interRatEsDeactivationCandidateCellPar 
ameters CM Support Qualifier 


The condition is "The cell acts as a candidate cell" 
AND inter-RAT ESM is supported. 



5.3.7.4 Notifications 

The common notifications defined in subclause 5.6.1 are valid for this IOC, without exceptions or additions. 

5.3.8 IOC SONFunclnfo 



5.3.8.1 



Definition 



This IOC represents information of SON functions, to support SON coordination. In case of SON coordination function 
is located below Itf-N, this IOC is used together with SONCoordinationPolices IOC for SON coordination purpose. 

SONFunclnfo hierarchy rule: 

An NRM IOC instance X may name-contain an IOC SONFunclnfo instance T. The rule states that: 
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If X name-contains a SONFuncInfo instance T, then T is applicable to X. 

If X and all its superior instances do not name-contain any SONFuncInfo instance, then no SONFuncInfo 
instance is applicable to X. 

If X does not name-contain any SONFuncInfo instance, but one or more of X's superior instances name-contain 
a SONFuncInfo instance, then the SONFuncInfo instance of the superior instance closest to X, in X's naming 
tree, is applicable to X. 

5.3.8.2 Attributes 



Attribute Name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


sonFuncCapabilityBelowItfN 


M 


M 


- 



5.3.8.3 Attribute constraints 

None. 

5.3.8.4 Notifications 

The common notifications defined in subclause 5.6.1 are valid for this IOC, without exceptions or additions. 



5.3.9 IOC SONCoordinationPolicies 
5.3.9.1 Definition 

This IOC represents the SON coordination policies that are selected by IRPManagers from the IRP Agent supported 
policies in the case of a separate SON coordination function is located below Itf-N (i.e., EM centralized SON 
coordination) or SON coordination function is implemented as part of each SON function (i.e., distributed SON 
coordination). For EM centralized SON coordination case, the case that the SON function is located above Itf-N and the 
corresponding SON coordination function is below Itf-N is not in the scope of this release. 

This IOC is not intended to be used by IRPManager to create SON coordination policies that are not supported by 
IRP Agent. The selected SON coordination policies are used by SON coordination function to coordinate the SON 
functions with potential conflicts, in case no SON coordination policies are selected by IRPManager, the default SON 
coordination policies are applied to the SON coordination function below Itf-N; the default SON coordination policies 
are per agreement between IRPManager and IRP Agent, the value of the default SON coordination policies is out of the 
scope of this specification. 

SONCoordinationPolicies hierarchy rule: 

An NRM IOC instance X may name-contain an IOC SONCoordinationPolicies instance T. The rule states that: 

If X name-contains a SONCoordinationPolicies instance T, then T is applicable to X. 

If X and all its superior instances do not name-contain any SONCoordinationPolicies instance, then no 
SONCoordinationPolicies instance is applicable to X. 

If X does not name-contain any SONCoordinationPolicies instance, but one or more of X's superior instances 
name-contain a SONCoordinationPolicies instance, then the SONCoordinationPolicies instance of the superior 
instance closest to X, in X's naming tree, is applicable to X. 
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5.3.9.2 



Attributes 



Attribute Name 


Support Qualifier 


Read Qualifier 


Write Qualifier 


select edSonCoordPol icy 


CM 


M 


M 


sonFuncPriorityOrder 


CM 


M 


M 



5.3.9.3 



Attribute constraints 



Name 


Definition 


selectedSonCoordPolicy CM 
Support Qualifier 


SON coordination function below Itf-N supports more than one 
coordination policy. 


sonFuncPriorityOrder CM 
Support Qualifier 


The selectedSonCoordPolicy equals to 
"BaseOnPriority". 



5.3.9.4 Notifications 

The common notifications defined in subclause 5.6.1 are valid for this IOC, without exceptions or additions. 

5.4 Information relationship definitions 

None. 
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5.5 



Information attribute definitions 



5.5.1 Definition and legal values 

Table 5.5.1.1 defines the attributes that are present in the Information Object Classes (lOCs) of the present document. 

Table 5.5.1.1 : Attributes definitions and legal values 



Attribute Name 


Definition 


Legal Values 


cocSwitch 


This attribute allows the operator to enable/disable 
the COG functionality. 


Enumerated {on, off} 


energySavingCo 
ntrol 


This attribute allows the IRPIVIanager to initiate 
energy saving activation or deactivation. Its value 
can not be changed by the IRPAgent. 


Enumerated 

{toBeEnergySaving, 
toBeNotEnergySaving}. 


energySavingSt 
ate 


Specifies the status regarding the energy saving in 

the cell. 

If the value of energySavingControl is 

toBeEnergySaving, then it shall be tried to 

achieve the value isEnergySaving for the 

energySavingState. 

If the value of energySavingControl is 

toBeNotEnergySaving, then it shall be tried to 

achieve the value isNotEnergySaving for the 

energySavingState. 


Enumerated 

{isNotEnergySaving, 
isEnergySaving}. 
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eRabAbnormalRe 
leaseRateChara 
cteristic 



The target is on the number of E-RAB abnormal 
release related to load divided by the total number 
of attempted E-RAB setups. 

This attribute allows to define for a value the 

composite available capacity (CAC) range in which 

the target is valid. For this, it contains one 

characteristic dependent on Uplinl< CAC, one for 

Downlink CAC: 

eRabAbnormalReleaseRateCharacteristicD 

ownlink and 

eRabAbnormalReleaseRateCharacteristicU 

plink. 

At least one of these charateristics must be present. 

Together with the characteristic its targetWeight as 

a SON target is defined as part of this attribute. 

The characteristics have the following structure: 

eRabAbnormalReleaseRateCharacteristicD 

ownlink : 

List of one or more entries, each consisting of: 

lowerEndOfCacRange, 

upperEndOfCacRange, 

e RabAbnormal ReleaseRateTarget 
eRabAbnormalReleaseRateCharacteristicU 
plink: 
List of one or more entries, each consisting of: 

lowerEndOfCacRange, 

upperEndOfCacRange, 

oRabAbnormalReleaseRateTarget 
Remark: 

Formula for composite available capacity: 
Available Capacity = Cell Capacity Class Value * 
Capacity Value 

For definition of Cell Capacity Class Value and 
Capacity Value see TS 36.331 [6]. These definitions 
lead to a value range of a composite available 
capacity from 0.. 10000. 

36.423 [7] has cell capacity class value as optional 
parameter in case of intra-LTE load balancing. If cell 
capacity class value is not present, than 36.423 
assumes that bandwidth should be used instead to 
assess the capacity. 

This target is suitable for LBO. 



lowerEndOfCacRange and 
UpperEndOfCacRange: 
Integer 0.. 10000 

eRabAbnormalReleaseRateTarget: 
Integer 0..100 (representing a 
percentage) 

targetWeight: 

Integer 1 ..N. The higher the number the 

higher the weight. 
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eRabSetupFailu 
reRateCharacte 
ristic 



The target is on the number of E-RAB setup failures 

related to load divided by the total number of 

attempted E-RAB setups. 

For E-RAB setup failure related to load the causes 

"Reduce load in serving cell" and "Radio resources 

not available" defined in TS 36.413 are used. 

This attribute allows to define for a value the 

composite available capacity (CAC) range in which 

the target is valid. For this, it contains one 

characteristic dependent on Uplink CAC, one for 

Downlink CAC: 

eRabSetupFailureRateCharacteristicDown 

link and 

eRabSetupFailureRateCharacteristicUpli 

nk. 

At least one of these charateristics must be present. 

Together with the characteristic its targetWeight as 

a SON target is defined as part of this attribute. 

The characteristics have the following structure: 

eRabSetupFailureRateCharacteristicDown 

link: 

List of one or more entries, each consisting of: 

LowerEndOfCacRange, 

UpperEndOfCacRange, 

oRabSetUpFailureRateTarget 
eRabSetupFailureRateCharacteristicUpli 
nk: 
List of one or more entries, each consisting of: 

LowerEndOfCacRange, 

UpperEndOfCacRange, 

ORabSetUpFailureRateTarget 
For CAC see 
eRabAbnormalReleaseRateCharacteristic 

This target is suitable for LBO. 



lowerEndOfCacRange and 

UpperEndOfCacRange and 

targetWeight: 

See 

eRabAbnormalReleaseRateCharacterist 

ic 

eRabSetUpFailureRateTarget: 
Integer 0..100 (representing a 
percentage) 



esActivationOr 
iginalCellLoad 
Parameters 



This attributes is relevant, if the cell acts as an 
original cell. 

This attribute indicates the traffic load threshold and 
the time duration, which are used by distributed ES 
algorithms to allow a cell to enter the energySaving 
state. The time duration indicates how long the load 
needs to have been below the threshold. 



Threshold: Integer 0.. 100 (Percentage 

of PRB usage, see 3GPP TS 36.314 

[13]) 

TimeDuration: Integer (in unit of 

seconds) 



esActivationCa 
ndidateCellsLo 
adParameters 



This attributes is relevant, if the cell acts as a 
candidate cell. 

This attribute indicates the traffic load threshold and 
the time duration, which are used by distributed ES 
algorithms level to allow a n 'original' cell to enter 
the energySaving state. Threshold and duration are 
applied to the candidate cell(s) which will provides 
coverage backup of an original cell when it is in the 
energySaving state. The threshold applies in the 
same way for a candidate cell, no matter for which 
original cell it will provide backup coverage. 
The time duration indicates how long the traffic in 
the candidate cell needs to have been below the 
threshold before any original cells which will be 
provided backup coverage by the candidate cell 
enters energy saving state. 



Threshold: Integer 0.. 100 (Percentage 

of PRB usage (see 3GPP TS 36.314 

[13])) 

TimeDuration: Integer (in unit of 

seconds) 
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esDeactivation 
CandidateCells 
LoadParameters 


This attributes is relevant, if the cell acts as a 
candidate cell. 

This attribute indicates the traffic load threshold 
and the time duration which is used by distributed 
ES algorithms to allow a cell to leave the 
energySaving state. Threshold and time duration 
are applied to the candidate cell when it which 
provides coverage backup for the cell in 
energySaving state. The threshold applies in the 
same way for a candidate cell, no matter for which 
original cell it provides backup coverage. 
The time duration indicates how long the traffic in 
the candidate cell needs to have been above the 
threshold to wake up one or more original cells 
which have been provided backup coverage by the 
candidate cell. 


Threshold: Integer 0.. 100 (Percentage 

of PRB usage (see 3GPP TS 36.314 

[13])) 

TimeDuration: Integer (in unit of 

seconds) 


esNotAllowedTi 
mePeriod 


This attribute can be used to prevent a cell entering 
energySaving state. 

This attribute indicates a list of time periods during 
which inter-RAT energy saving is not allowed. 

Time period is valid on the specified day and time of 
every week. 


The legal values are as follows: 
startTime and endTime: 
All values that indicate valid UTC time. 
endTime should be later than startTime. 

periodOfDay: structure of startTime and 
endTime. 

daysOfWeekList: list of weekday, 
weekday: Monday, Tuesday, ... 
Sunday. 

List of time periods: 

{{ daysOfWeek daysOfWeekList, 

periodOfDay dailyPeriod}} 


esSwitch 


This attribute determines whether the energy saving 
function is enabled or disabled. 


On, off 


hoFailureRate 


This indicates the assigned HOO target of the 
number of failure events related to handover divided 
by the total number of handover events, together 
with its targetWeight. 

This target is suitable for HOO or LBO. 


A set of two numbers: 

the first indicates a percentage, the 

second a targetWeight (see 

eRabAbnormalReleaseRateCharacterist 

ic). 


hooSwitch 


This attribute determines whether the Handover 
parameter Optimization Function is activated or 
deactivated. 


On, off 
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interRatEsActi 
vationOriginal 
CellParameters 


This attribute is relevant, if tlie cell acts as an 
original cell. 

This attribute indicates the traffic load threshold and 
the time duration, which are used by distributed 
inter-RAT ES algorithms to allow an original cell to 
enter the energySaving state. The time duration 
indicates how long the traffic load (both for UL and 
DL) needs to have been below the threshold. 

In case the original cell is an EUTRAN cell, the 
load information refers to Composite Available 
Capacity Group IE (see 3GPP TS 36.413 [12] 
Annex B.I .5) and the following applies: 
Load = (1 00 - 'Capacity Value' ) * 'Cell Capacity 
Class Value', where 'Capacity Value' and 'Cell 
Capacity Class Value' are defined in 3GPP TS 
36.423 [16]. 

In case the original cell is a UTRAN cell, the load 
information refers to Cell Load Information Group IE 
(see 3GPP TS 36.413 [1 2] Annex B.I .5) and the 
following applies: 

Load= 'Load Value' * 'Cell Capacity Class Value', 
where 'Load Value' and 'Cell Capacity Class Value' 
are defined in 3GPP TS 25.413 [17]. 

If the 'Cell Capacity Class Value' is not known, then 
'Cell Capacity Class Value' should be set to 1 when 
calculating the load, and the load threshold should 
be set in range of 0.. 100. 


InterRatESActivationOriginalCellParam 

eters: 

Structure: 

LoadThreshold: Integer 0.. 10000 
TimeDuration: Integer 0..900 (in unit of 
seconds) 
} 


interRatEsActi 
vationCandidat 
eCell Parameter 
s 


This attribute is relevant, if the cell acts as a 
candidate cell. 

This attribute indicates the traffic load threshold and 
the time duration, which are used by distributed 
inter-RAT ES algorithms to allow an original cell to 
enter the energySaving state. Threshold and time 
duration are applied to the candidate cell(s) which 
will provides coverage backup of an original cell 
when it is in the energySaving state. 
The time duration indicates how long the traffic load 
(both for UL and DL) in the candidate cell needs to 
have been below the threshold before any original 
cells which will be provided backup coverage by the 
candidate cell enters energySaving state. 

In case the candidate cell is a UTRAN or GERAN 
cell, the load information refers to Cell Load 
Information Group IE(see 3GPP TS 36.413 [12] 
Annex B.I .5) and the following applies: 
Load= 'Load Value' * 'Cell Capacity Class Value', 
where 'Load Value' and 'Cell Capacity Class Value' 
are defined in 3GPP TS 25.413 [1 7] (for UTRAN) / 
TS48.008[18](forGERAN). 

If the 'Cell Capacity Class Value' is not known, then 
'Cell Capacity Class Value' should be set to 1 when 
calculating the load, and the load threshold should 
beset in range of 0.. 100. 


InterRatEsActivationCandidateCellPara 

meters: 

Structure 

{ 

LoadThreshold: Integer 0.. 10000 

TimeDuration: Integer 0..900 (in unit of 

seconds) 

} 
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interRatEsDeac 
t ivat ionCandid 
ateCellParamet 
ers 


This attribute is relevant, if the cell acts as a 
candidate cell. 

This attribute indicates the traffic load threshold and 
the time duration which is used by distributed inter- 
RAT ES algorithms to allow an original cell to leave 
the energySaving state. Threshold and time 
duration are applied to the candidate cell which 
provides coverage backup for the cell in 
energySaving state. 

The time duration indicates how long the traffic load 
(either for UL or DL) in the candidate cell needs to 
have been above the threshold to wake up one or 
more original cells which have been provided 
backup coverage by the candidate cell. 

For the load see the definition of 
InterRatEsActivationCandidateCellParameters. 


InterRatEsDeactivationCandidateCellPa 

rameters: 

See 

InterRatEsActivationCandidateCellPara 

meters 


IboSwitch 


This attribute determines whether the Load 
Balancing Optimization Function is activated or 
deactivated. 


On, off 


maximumDeviati 
onHoTrigger 


This parameter allows the IRPManager to define the 
maximum allowed absolute deviation of the cell pair 
specific part of Handover Trigger (as defined in [14] 
(§22.4.1 .4), from the default point of operation 


Integer (+1.. +96) 
Unit: 0.5 dB 


isProbingCapab 
le 


This attribute indicates whether this cell is capable 
of performing the ES probing procedure. During this 
procedure the eNB owning the cell indicates its 
presence to UEs for measurement purposes, but 
prevents idle mode UEs from camping on the cell 
and prevents incoming handovers to the same cell. 
If this parameter is absent, then probing is not done. 


Boolean 


minimumTimeBet 
weenHoTriggerC 
hange 


This parameter defines the minimum allowed time 
interval between two changes of the Handover 
Trigger performed by IVIRO. 


Integer (0.. 1440) 
Unit: IVIinutes 
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This is a list of target Access Delay probability {ADp) 
for the RACH optimization function. 

Each instance ADp of the list is the target time 
before the UE gets access on the random access 
channel, for the P percent of the successful RACH 
Access attempts with lowest access delay, over an 
unspecified sampling period. 

This target is suitable for RO. 



rachOptAccessD 
elayProbabilit 
Y 



This is a list of target Access Probability {APn) for 
the RACH optimization function. 

Each instance APn of the list is the probability that 
the UE gets access on the random access channel 
within n number of attempts, over an unspecified 
sampling period. 

This target is suitable for RO. 



Each element of the list, ADpn, is a pair 
(a, b) where a is the targetProbability (in 
%) and b is the access delay (in 
milliseconds). 

The legal values for a are 25, 50, 75, 

90. 

The legal values for b are 10 to 560. 

If ADpx's a is larger than that of ADpy, 
then ADpxS b must be larger than that 

of ADpy. 

The number of elements specified is 4. 
The number of elements supported is 
vendor specific. The choice of 
supported values for a and b is vendor- 
specific. 



rachOptAccessP 
robability 



Each element of the list, APn, is a pair 
(a, n) where a is the targetProbability (in 
%) and n is the access attempt number. 

The legal values for a are 25, 50, 75, 

90. 

The legal values for n are 1 to 200. 

If APxS a is larger than that of APy, then 
APx's n must be larger than that of APy. 

The number of elements specified is 4. 
The number of elements supported is 
vendor specific. The choice of 
supported values for a and n is vendor- 
specific. 



roSwitch 



This attribute determines whether the RACH 
Optimization function is activated or deactivated. 



On, off 
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rrcConnectionA 
bnormalRe lease 
RateCharacteri 
Stic 



The target is on the number of abnormal RRC 
connection releases related to load divided by the 
total number of RRC connection releases. 

This attribute allows to define for a value the 
composite available capacity (CAC) range in which 
the target is valid. For this, it contains one 
characteristic dependent on Uplinl< CAC, one for 
Downlink CAC: 

rrcConnectionAbnormalReleaseRateCharac 
teristicDownlink and 

rrcConnectionAbnormalReleaseRateCharac 
teristicUplink . 

At least one of these charateristics must be present. 
Together with the characteristic its targetWeight as 
a SON target is defined as part of this attribute. 
The characteristics have the following structure: 
rrcConnectionAbnormalReleaseRateCharac 
teristicDownlink : 
List of one or more entries, each consisting of: 

lowerEndOfCacRange, 

upperEndOfCacRange, 

rrcConnectionAbnormalReleaseRateTarget 
rrcConnectionAbnormalReleaseCharacteri 
sticUplink: 
List of one or more entries, each consisting of: 

lowerEndOfCacRange, 

upperEndOfCacRange, 

rrcConnectionAbnormalReleaseRateTarget 
For CAC see 
eRabAbnormalReleaseRateCharacteristic 

This target is suitable for LBO. 



lowerEndOfCacRange and 

UpperEndOfCacRange and 

targetWeight: 

See 

eRabAbnormalReleaseRateCharacterist 

ic 

rrcConnectionAbnormalReleaseRateTar 

get: 

Integer 0..100 (representing a 

percentage) 



rrcConnectionE 
stablishmentFa 
ilureRateChara 
cteristic 



The target is on the number of RRC connection 
establishment failures related to load divided by the 
total number of attempted RRC connection 
establishments. 

This attribute allows to define for a value the 
composite available capacity (CAC) range in which 
the target is valid. For this, it contains one 
characteristic dependent on Uplinl< CAC, one for 
Downlink CAC: 

rrcConnectionEstablishmentFailureRateC 
haracteristicDownlink and 
rrcConnectionEstablishmentFailureRateC 
haracteristicUplink . 
At least one of these charateristics must be present. 
Together with the characteristic its targetWeigth as 
a SON target is defined as part of this attribute. 
The characteristics have the following structure: 
rrcConnectionEstablishmentFailureRateC 
haracteristicDownlink : 
List of one or more entries, each consisting of: 

lowerEndOfCacRange, 

upperEndOfCacRange, 

rrcConnectionEstablishmentFailureRateTarget 
rrcConnectionEstablishmentFailureRateC 
haracteristicUplink : 
List of one or more entries, each consisting of: 

lowerEndOfCacRange, 

UpperEndOfCacRange, 

rrcConnectionEstablishmentFailureRateTarget 
For CAC see 
eRabAbnormalReleaseRateCharacteristic 

This target is suitable for LBO. 



lowerEndOfCacRange and 

UpperEndOfCacRange and 

targetWeigth: 

See 

eRabAbnormalReleaseRateCharacterist 

ic 

rrcConnectionEstablishmentFailureRate 

Target: 

Integer 0..100 (representing a 

percentage) 
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select edSonCoo 
rdPolicy 


This attribute indicates the SON coordination policy 
that is selected by IRPManager in case the SON 
coordination function is located below Itf-N. 
The selected SON coordination policy is one of the 
enumed value from BaseOnPriority and 
BaseOnState, wherein 

- BaseOnPriority, representing that the coordination 
is based on the priority order of the SON functions 
listed in "sonFuncPriorityOrder" attribute; 

- BaseOnState, representing the coordination is 
based on the cell state. 

The examples of SON coordination for some certain 
conflicting cases based on priority and state are 
depicted in Annex B. 


Enumerated {BaseOnPriority, 
BaseOnState} 


sonFuncCapabil 
ityBelowItfN 


This attributes represents the SON functions 
supported below Itf-N. 

It is a list of SON function name. The SON function 
name is one of the enumed value from anr, hoo, Ibo, 
es, coc and ceo, wherein 

- anr repesenting automated neighbor relation; 

- hoo representing handover parameter 
optimization; 

- Ibo representing load balancing optimization; 

- es representing energy saving; 

- coc representing cell outage compensation; 

- ceo representing coverage and capacity 
optimization. 


List of SON function name. 

SON function name: Enumerated {anr, 

hoo, Ibo, es, coc, ceo} 


sonFuncPriorit 
yOrder 


This attribute indicates the priority order of SON 

functions below Itf-N for SON coordination purpose, 

in case the selectedSonCoordPolicy equals to 

"BaseOnPriority". 

It is a list of SON function name, see the detailed 

description in "sonFuncCapabilityBelowItfN" 

attribute. 

The priority order Is indicated by the sequence of 

the SON function name in the list, i.e., the first 

element in the list takes the highest priority, and the 

last element in the list takes the lowest priority. 

In case of selectedSonCoordPolicy does not 

equal to "BaseOnPriority", this sequence of the SON 

function name in the list is not used as priority order 

for SON coordination. 


List of SON function name: for SON 
function name, see 

"sonFuncCapabilityBelowItfN" 
attribute. 



5.5.2 

None. 

5.6 
5.6.1 



Constraints 



Common Notifications 
Configuration notifications 



Name 


Qualifier 


Notes 


notifyAttributeValueChange 







notifyObjectCreation 







notifyObjectDeletion 
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Annex A (informative): 

Target Achievement Evaluation 



To evaluate the result of the optimization the target achievement needs to be evaluated. This can be done by 
calculating the Total Target Achievement as follows. 

The Total Target Achievement is the sum of the products of the individual target achievement (difference between 
target and performance) and the individual targetWeights: 

Total Target Achievement = 

Sum i^i n [ ( minTarget j - performance i ) x weight] ] 
+ Sum j^i n [ performance j - maxTarget j ) x weight j ] 

where minTarget is a target to be minimized and maxTarget is a target to be maximized. 

For targets with a substructure (like *Characteristic , see §5.5.1) the above formula is applied 
to each individual substructure target. 

The higher the Total Target Achievement, the better is the result of the optimization. 
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Annex B (informative): 

Examples of how to use general SON coordination solutions 

Examples of how to use general SON coordination solutions are as below: 

B.1 Coordination of COC and CCO using priority of SON 
functions 

To prevent conflicting setting as illustrated in clause 4.7.3.2.1, the cell(s) which may need to be coordinated between 
COC and CCO, i.e., the impact area information, should be known by the SON Coordination Function. By 
comparing the priorities of COC and CCO, SON Coordination Function will decide to do the high-priority action 
and suspend the low-priority action on the coordinated cell(s). The priorities of COC and CCO can be preset by 
operator to SON Coordination Function, or SON Coordination Function inquires the default priority of COC and 
CCO to each of them. 

The cell which needs to be coordinated between COC and CCO is: 

- The cell in which there is coverage or capacity problem and CCO action is needed, meanwhile the cell is 

outage or compensating or going to compensate for outage; or 

- The cell which is located in the CCO optimization analysis area for other cell which has coverage or capacity 

problem, meanwhile the cell is outage or compensating or going to compensating for outage; 

After the high-priority SON function executes action, the SON Coordination Function is informed about the result 
(successful/unsuccessful, parameters changes) of the executed high-priority SON action. Then, SON Coordination 
Function will analyse the latest network situation to decide how to deal with the suspended low-priority SON action, 
for example, resuming or rejecting. 



B.2 Coordination of COC, CCO and ES using priority of 
SON functions 

To prevent conflicting adjustment from COC, ES and optimization from CCO in the common affected cell(s) (e.g.. 
Cell 2 in the Figure 4.7.3.2), the cell(s) which may need to be coordinated among COC, CCO and ES, i.e., the 
impact area information, should be known by the SON Coordination Function. By comparing the priorities of COC, 
CCO and ES, SON Coordination Function will decide to do the highest-priority action and suspend the low-priority 
actions on the coordinated cell(s). The priorities of COC, CCO and ES can be preset by operator to SON 
Coordination Function, or SON Coordination Function inquires the default priority of COC, CCO and ES to each of 
them. 

The cell which needs to be coordinated among COC, CCO and ES is: 

- The cell in which there is coverage or capacity problem and CCO action is needed, meanwhile the cell is 

outage or compensating or going to compensate for outage or ES; or 

- The cell which is located in the CCO optimization analysis area for other cell which has coverage or capacity 

problem, meanwhile the cell is outage or compensating or going to compensate for outage or ES; 

After the highest-priority SON function executes action, the SON Coordination Function is informed about the 
result (successful/unsuccessful, parameters changes) of the executed highest-priority SON action. Then, SON 
Coordination Function will analyse the latest network situation to decide how to deal with the suspended low- 
priority SON actions, for example, resuming or rejecting. 
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B.3 Coordination of COC, CCO and ES based on the cell 
state 

The following lists the examples of how SON Coordination Function (SCF) can resolve the conflicts between COC, 
CCO, and ES functions based on cell state. Although not shown, priority may be used to along with the cell state to 
resolve the conflicts. 

Possible conflict #1: COC requests a cell that is compensating an energy saving cell to compensate an outage cell 

Resolution: When COC requests SCF that cell A is going to compensate an outaged cell, SCF should check whether 
cell A is compensating an energy saving cell. If so, SCF should check whether cell A can compensate both the outage 
cell and the energy saving cell concurrently. If not, the SCF may disallow cell A to compensate an energy saving cell. 



Possible conflict #2: COC requests a cell that is being changed or going to be changed by CCO to compensate an 
outage cell 

Resolution: When COC requests SCF that cell A is going to compensate an outaged cell, SCF should check whether 
CCO is updating parameters to optimize the capacity and coverage of cell A. If so, SCF may not allow cell A to 
compensate an outaged cell; otherwise SCF should allow cell A to compensate an outage cell. 



Possible conflict #3: ES requests a candidate cell that is compensating an outage cell to compensate an energy saving 
cell 

Resolution: When ES request SCF that cell A is to compensate a cell going to enter energy saving, SCF should check 
the cOCStatus . state of cell A. If cOCStatus . state = cOCCompensating, SCF should check whether cell 
A can compensate both the outage cell and the energy saving cell concurrently. If not, the SCF may disallow cell A to 
compensate an energy saving cell. 



Possible conflict #4: ES requests a cell that is being changed or going to be changed by CCO to compensate an energy 
saving cell 

Resolution: When ES requests SCF that cell A is going to compensate a cell going to enter energy saving, SCF should 
check whether CCO is updating parameters to optimize the capacity and coverage of cell A. If so, SCF may not allow 
cell A to compensate an energy saving cell; otherwise SCF should allow cell A to compensate an outage celL 



Possible conflict #5: CCO is going to change the configuration parameter of a cell that is compensating an outage cell 

Resolution: When CCO requests SCF that cell A is going to change the configuration parameter, SCF should check the 
cOCStatus . state of cell A. If cOCStatus . state = cOCCompensating, SCF should disallow cell A to 
change the configuration parameter. 
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Annex C (informative): 

State diagram for Distributed and ElVI-centralized Energy 

Saving IVIanagement 

Energy Saving Management "state" attributes are available at various levels: 

SubNetwork IOC level, via the attribute esSwitch defined in the IOC SonControl; 

ENBFunction IOC level, via the attribute esSwitch defined in the IOC SonControl; 

EUtranGenericCell IOC level, via the locally defined attribute isChangeForEnergySavingAUowed, and via the 
attribute energySavingState defined in the IOC EnergySavingProperties. 



The following figure provides an overview of Energy Saving Management related lOCs, state attribute names and 
possible values, for Distributed and EM-centralized Energy Saving Management: 



« Info rmationObje etc ldss» 
TS 32 .622:: Sub Network 




«lnformationObjectCla£s» 
TS32.S22::S0NCorftrol 



«name£» 



« I nf rm atio n bj e ctC I asss 
TS 32.762::ENBFunction 



«nameSB 


«lriformationObjectClass» 
TS32.522::ESPolicies 




0.." 









T\ 



ES-related sta-te attribute: 
esSiruitch (RSW) [On, Off] 





t 1 

0.." 












ES-related state attribute: 
isCtiangeForEnergvSavingAlloiAied (RAAQ [Yes, No] 


^ 


«lnformati(jnObjectCla££» 
TS 32.782::EUtranGenericCell 










Vi 









« I nf rm atio n bj e cd:C I asss 

TS 32.522:: 
EnergySavi ng Properti es 



T\ 



ES-related state attribute: 

energySavingState (R) [isEnergySaving, isNotEnergySaving] 



Figure C-1 : lOCs and state attributes for Distributed and ElVI-centralized ESM 

Dependencies exist between distributed ESM state attributes. The diagram below shows which allowed combinations of 
attribute state values, and which state transitions, are valid and which are not. 
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Figure C-2: State diagram for Distributed and ElVI-centralized ESIUI 



Description: 

a) The ESM-related state attribute esSwitch is used by IRPManager to switch on / off the ESM functionaUty, in the 
distributed and EM-centraUzed architectures. This attribute has two possible values: On, Off. It can be set at the 
sub -network level and at the eNodeB level; 

b) The ESM-related state attribute LsChangeForEnergySavingAllowed is used by IRPManager to prohibit or allow 
configuration changes of cells individually, within a eNodeB / sub-network, for ESM purposes by the IRPAgent. 
This attribute has two possible values: Yes, No. 

c) The ESM-related state attribute esState is used to reflect the actual status of a cell regarding the energy saving. 
This attribute has two possible values: isEnergySaving, isNotEnergySaving. 

Figure C-2 describes the following state transitions: 

1) Transition from {esSwitch = On and isChangeForEnergySavingAllowed = Yes and esState = 
isNotEnergySaving) to((esSwitch = On and isChangeForEnergySavingAllowed = Yesand esState = 
isEnergySaving): happens when: 

ES Policies attached to the subject cell and to candidate for compensation cells, e.g. threshold and duration, are 
satisfied and allow entering Energy Saving state. 

2) Transition from (esSwitch = On and IsChangeForEnergySavingAllowed = Yes and esState = isEnergySaving) 
to{esSwitch = On and IsChangeForEnergySavingAllowed = Yes and esState = isNotEnergySaving): happens 
when: 

ES Policies attached to the subject cell and to candidate for compensation cells, e.g. threshold and duration, are 
satisfied and allow leaving Energy Saving state. 

3) Transition from (esSwitch = On and IsChangeForEnergySavingAllowed = Yes) to (esSwitch = On and 
IsChangeForEnergySavingAllowed = No and esState = isNotEnergySaving): happens when: 

IRP Manager sets the attribute IsChangeForEnergySavingAllowed to "No". 
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4) Transition from (esSwitch = On and isChangeForEnergySavingAllowed = No and esState = isNotEnergySaving) 
to isChangeForEnergySavingAllowed = Yes: happens when: 

IRP Manager sets the attribute IsChangeForEnergySavingAllowed to "Yes". 

5) Transition from {esSwitch = On and IsChangeForEnergySavingAllowed = Yes) to( esSwitch = Off and 
IsChangeForEnergySavingAllowed = Yes and esState = isNotEnergySaving): happens when: 

IRP Manager sets the attribute esSwitch to "Off. 

6) Transition from (esSwitch = Off and IsChangeForEnergySavingAllowed = Yes and esState = 
isNotEnergySaving) to (esSwitch = On and IsChangeForEnergySavingAllowed = Yes and esState = 
isNotEnergySaving): happens when: 

IRP Manager sets the attribute esSwitch to "On". 

7) Transition from (esSwitch = On and IsChangeForEnergySavingAllowed = No and esState = isNotEnergySaving) 
to (esSwitch = Off and IsChangeForEnergySavingAllowed = No and esState = isNotEnergySaving): happens 
when: 

IRP Manager sets the attribute esSwitch to "Off. 

8) Transition from (esSwitch = Off and IsChangeForEnergySavingAllowed = No and esState = isNotEnergySaving) 
to (esSwitch = On and IsChangeForEnergySavingAllowed = No and esState = isNotEnergySaving): happens 
when: 

IRP Manager sets the attribute esSwitch to "On". 
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Annex D (informative): 
Change history 
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- 


1.0.0 


2010-03 


- 


- 


- 


- 


Publication of SA approved version 


1.0.0 


9.0.0 


2010-09 


SA#49 


SP-1 00491 


001 


- 


Remove targets based on not supported by measurements 


9.0.0 


9.1.0 


2010-12 


SA#50 


SP-1 00858 


003 


1 


Correcting the support qualifiers of SONControl attributes 


9.1.0 


9.2.0 


2010-12 


SA#50 


SP-1 00749 


005 


- 


Disambiguate and correct the description of SON Targets hierarchy 


9.1.0 


9.2.0 


2010-12 


SA#50 


SP-1 00833 


002 


3 


Allow EM centralized architecture for Hand-over parameter 
optimization - Align with 32.500 


9.2.0 


10.0.0 


2010-12 


SA#50 


SP-1 00866 


004 


3 


Adding NRM for Energy Saving Management policies and ESM 
switch 


9.2.0 


10.0.0 


2011-01 


— 


— 


— 


- 


Correction of misimplementation of CR in clause 5.3.2.3 and CR 
history correction. 


10.0.0 


10.0.1 


2011-03 


SA#51 


SP-1 10098 


010 


2 


Introducing RACH optimization management 


10.0.1 


10.1.0 


2011-03 


SA#51 


SP-1 10098 


oil 


- 


Rapporteur clean-up for editorial errors 


10.0.1 


10.1.0 


2011-03 


SA#51 


SP-1 10100 


013 


3 


Use ESPolicies also for EM centralized architecture 


10.0.1 


10.1.0 


2011-03 


SA#51 


SP-1 10100 


014 


- 


Correct cardinality of ESPolicies 


10.0.1 


10.1.0 


2011-03 


SA#51 


SP-1 10097 


016 




Add a new attribute into SONControl object class to switch on/off 
Cell Outage Compensation - Align with 32.541 


10.0.1 


10.1.0 


2011-06 


SA#52 


SP-1 10284 


018 


1 


Finalization of Rel-10 SON functionalities 


10.1.0 


10.2.0 


2011-06 


SA#52 


SP-1 10284 


066 


2 


Add parameters to control Mobility Robustness Optimization 


10.1.0 


10.2.0 


2011-09 


SA#53 


SP-1 10634 


066a 


1 


Add PM for Inter-RAT MRO 


10.2.0 


11.0.0 


2011-12 


SA#54 


SP-1 1071 8 


068 


1 


Adding definition of SON coordination 


11.0.0 


11.1.0 


2011-12 


SA#54 


SP-1 10721 


071 


1 


Correction MRO management of HO Trigger 


11.0.0 


11.1.0 


2012-06 


SA#56 


SP-1 20364 


078 


1 


Adding coordination use case among CCO, COC and ESM 


11.1.0 


11.2.0 


2012-06 


SA#56 


SP-1 20358 


087 


- 


Remove the EUTRANRelationSON in the UML 


11.1.0 


11.2.0 


2012-06 


SA#56 


SP-1 20364 


088 


1 


Add SON Coordination use case between SON functions below Itf- 
N and CM operations over Itf-N 


11.1.0 


11.2.0 


2012-06 


SA#56 


SP-1 20364 


091 


2 


Common SON coordination solution 


11.1.0 


11.2.0 


2012-06 


SA#56 


SP-1 20371 


092 


1 


Add time period configuration to allow inter-RAT energy saving 


11.1.0 


11.2.0 


2012-09 


SA#57 


SP-1 20645 


096 


2 


Remove Inter-RAT ES restriction for esNotAllowedTlmePeriod 


11.2.0 


11.3.0 


2012-09 


SA#57 


SP-1 20645 


098 


2 


Correct candidateCellLoadParameters 


11.2.0 


11.3.0 


2012-09 


SA#57 


SP-1 20573 


103 


- 


Add support for Inter-RAT Energy Saving Management 


11.2.0 


11.3.0 


2012-09 


SA#57 


SP-1 20567 


105 


- 


Move SON coordination concept description to TS 32.521 


11.2.0 


11.3.0 


2012-09 


SA#57 


SP-1 20567 


107 


1 


Coordination between ES and cell compensation 


11.2.0 


11.3.0 


2012-09 


SA#57 


SP-1 20567 


108 


3 


Change description of Coordination between SON functions below 
Itf-N and CM operations over Itf-N 


11.2.0 


11.3.0 


2012-09 


SA#57 


SP-1 20567 


109 


2 


Enhancement of general SON coordination solutions 


11.2.0 


11.3.0 


2012-09 


SA#57 


SP-1 20567 


110 


2 


Add examples of how to use general SON coordination solutions 


11.2.0 


11.3.0 


2012-12 


SA#58 


SP-1 20791 


111 


2 


Correcting function name 


11.3.0 


11.4.0 


SP-1 20783 


114 


- 


Clean-up changes 


SP-1 20791 


115 


2 


Further enhancement of general SON coordination solutions 


SP-1 20791 


117 


2 


Add description for Coordination between SON functions below Itf- 
N and non-SON operations over Itf-N 


SP-1 20791 


119 


2 


Add conflict detection for general SON coordination solutions 


SP-1 20800 


120 


5 


Add load threshold parameters to Inter-RAT energy saving policy 


SP-1 20791 


125 


1 


Coordination between COC and ANR 


SP-1 20791 


126 


1 


Coordination between HOO and LBO 


SP-1 20791 


127 


1 


Add relationship diagram for SON coordination 


SP-1 20783 


128 


3 


Addition of probing state and its control for Energy Saving 


SP-1 20800 


131 


- 


Enhance esNotAllowedTimePeriod text description to fulfil energy 
saving allowed or prohibited for an EUTRAN cell 


2013-03 


SA#59 


SP-1 30056 


104 


7 


SON Coordination NRMs 


11.4.0 


11.5.0 


SP-1 30048 


132 


2 


Add informative annex on Distributed ES State Management 


SP-1 30056 


133 


2 


Add coordination example based on cell state 


2013-03 










Editorial correction of the spec title 


11.5.0 


11.5.1 


2013-06 


SA#60 


SP-1 30266 


134 


1 


Correction of attribute constraints 


11.5.1 


11.6.0 


SP-1 30266 


135 


1 


Remove EUtranRelationSON in UML diagram 


SP-1 30304 


136 


1 


Correcting error in attribute constraint 


SP-1 30304 


139 


- 


Correct the attribute constraint of energySavingControl 


2013-06 










Fixes typo in history table 


11.6.0 


11.6.1 



£75/ 
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History 



Document history 


Vll.3.0 


September 2012 


Publication 


VI 1.4.0 


February 2013 


Publication 


Vll.5.1 


April 2013 


Publication 


Vll.6.1 


July 2013 


Publication 









£75/ 



